## **Related issues**

Fixes: #23222
- issue where URL canonicalization was not properly sorting due to the
way that `.sort` works on React Native.
- add case for `sig_params` being empty, so that we can still sign links
without any parameters that need to be signed
- removed edge case unit test since it added very little value (no one
should be using spaces in a signed URL)

## **Description**

**Reason for change:**
Deep link signature verification was failing for marketing links (e.g.,
`https://link.metamask.io/perps?sig_params=...&utm_...`). The Mobile
app's `canonicalize` function had diverged from the Extension's
implementation, causing signature mismatches.

The root cause: **React Native's `URLSearchParams.sort()` is not
implemented** — it throws an error. This meant parameters weren't being
sorted correctly, so the canonical URL didn't match what was signed.

**Improvement/solution:**
Updated the `canonicalize` function to:

1. **Use custom array sorting** instead of `URLSearchParams.sort()`
(which is broken in React Native)
2. **Handle empty `sig_params` explicitly** — when `sig_params=''`, only
include `sig_params` itself in the canonical URL (allows appending UTMs
after signing)
3. **Use `getAll()`/`append()`** instead of `get()`/`set()` to preserve
multiple values for the same parameter (matches Extension behavior)
4. **Use `encodeURIComponent()`** for consistent URL encoding

These changes align Mobile with the Extension's canonicalization logic,
ensuring signed deep links verify correctly.

## **Changelog**

CHANGELOG entry: Fixed deep link signature verification failing for
marketing links with UTM parameters

## **Manual testing steps**

```gherkin
Feature: Deep Link Signature Verification

  Scenario: user opens a signed deep link with sig_params and appended UTMs
    Given a signed deep link with sig_params listing specific parameters
    And UTM parameters are appended after signing

    When user opens the deep link in the app
    Then the signature verifies successfully
    And the user is not shown the unsigned link warning modal

  Scenario: user opens a signed deep link with empty sig_params
    Given a signed deep link with sig_params= (empty)
    And UTM parameters are appended after signing

    When user opens the deep link in the app
    Then the signature verifies successfully
    And only sig_params is used for verification (UTMs ignored)

  Scenario: user opens a signed deep link without sig_params (legacy)
    Given a signed deep link without any sig_params parameter

    When user opens the deep link in the app
    Then all parameters (except sig) are included in verification
    And the signature verifies successfully (backward compatibility)
```

## **Screenshots/Recordings**

### **Before**

Signed marketing links showed the "unsigned link" warning modal due to
signature verification failure.

### **After**

Signed marketing links verify correctly and open without the warning
modal.

## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

---

**Labels to add:** `team-mobile-platform`

## **Description**

When there's no active season, we shouldn't show point estimations.

## **Changelog**

CHANGELOG entry: no point estimation when no active season

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Introduce RewardsController:hasActiveSeason and update hooks to stop
showing rewards/estimating points when no active season, with extensive
tests and minor controller refactors.
> 
> - **Controller (RewardsController)**:
> - **New API**: Add `RewardsController:hasActiveSeason` with
date-window check via `getSeasonMetadata('current')`; register action
and types.
> - **Behavior**: Gate `estimatePoints` behind `hasActiveSeason` (return
`{ pointsEstimate: 0, bonusBips: 0 }` when inactive).
> - **Refactor**: Add `setActiveAccountFromCandidate` and use it in
`handleAuthenticationTrigger`.
> - **Tests**: Add comprehensive tests for `hasActiveSeason`,
`estimatePoints` gating, and new helper.
> - **Hooks/UI**:
> - **Bridge/Perps/Predict hooks**: Replace `isRewardsFeatureEnabled`
checks with `hasActiveSeason`; short-circuit UI (no row, no estimation)
when inactive.
> - **Tests**: Update all related tests to use `hasActiveSeason` and
cover inactive-season paths.
> - **Types**:
> - Add `RewardsControllerHasActiveSeasonAction` and include in
`RewardsControllerActions`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
861008a. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry:

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [x] I’ve followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Large Hyperliquid docs update: add Info/validation/tick-size docs,
finalize and consolidate HIP‑3 specs (also in HIP‑2), extend HIP‑1, and
adjust exchange API (DEX abstraction rename + validator risk‑free rate
vote).
> 
> - **Docs (major additions)**:
> - Add `docs/perps/hyperliquid/info-endpoint.md` with comprehensive
Info API references (mids, orders, fills, books, candles, fees, staking,
vaults, referrals, HIP-3 DEX abstraction state, aligned quote token
status).
> - Add `docs/perps/hyperliquid/frontend-checks.md` outlining
client-side validations for HIP‑1 deployments (decimals, fee share,
genesis, Hyperliquidity limits).
> - Add `docs/perps/hyperliquid/tick-lotsize.md` detailing price/size
precision rules.
> - **HIP specs**:
> - Update `HIP-3.md` to finalized, permissionless builder‑deployed
perps with a consolidated **Spec**, **Settlement**, **Oracle**, and
**Slashing**; remove testnet/MVP language.
> - Replace `HIP-2.md` content with HIP‑3 (builder‑deployed perps) spec
for consistency.
> - Enhance `HIP-1.md` with a new "Deploying existing assets" section
and legacy deployer fee‑share policy; clarify spot dusting text.
> - **API changes (Exchange endpoint)**:
> - Rename DEX abstraction action to `userDexAbstraction` in request
schema.
> - Add validator action: `validatorL1Stream` to vote on risk‑free rate
for aligned quote assets.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
1d29f30. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

…te is available for BackgroundBridge (#22749)

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

Fixes an issue where MM Connect deeplinks do not result in an approval
being shown to the user from app cold start AND (?) if the app is an
expo build that gets delayed by bundling.

~~1. For some reason we do not restore connections the first ReactNative
AppState "active" event, which is the only one we receive. Guard has
been removed~~ Tamas has clarified why this is the case. I have reverted
this change
2. Our check to ensure the store is fully initialized is not complete
enough and was resulting in BackgroundBridge throwing when trying to
access state from the NetworkController that was not ready.

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
3. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: null


No changelog as MetaMask Connect has not been released to public yet

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [ ] I’ve followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.




<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> Adds store readiness check (including NetworkController state) to RPC
bridge init and increases readiness polling intervals; updates tests
accordingly.
> 
> - **SDKConnectV2 readiness**:
> - `when-store-ready`: New util ensuring `store.dispatch` and
`engine.backgroundState.NetworkController` exist before proceeding.
> - `when-engine-ready`/`when-store-ready`: Increase polling interval
from 10ms to 100ms.
> - **RPC bridge initialization**:
> - `RPCBridgeAdapter` tests updated to wait for `whenEngineReady`,
`whenOnboardingComplete`, and new `whenStoreReady` before creating
`BackgroundBridge` and subscribing to unlock events; ensure idempotent
init and queuing behavior.
> - **Tests**:
> - Update timer advances to match slower polling (milliseconds →
seconds) in `when-engine-ready.test.ts` and `when-store-ready.test.ts`.
> - `connection-registry.test.ts`: Mock store state to include
`NetworkController` for initialization-dependent flows.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
570282b. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: aphex <52055541+wenfix@users.noreply.github.com>